<html>
    <head>
    <link rel="stylesheet" href="lmm.css" type="text/css" />
    </head>
<body class="lmm">
<!-- This file is part of the Lisp Machine manual.	-*-Text-*- -->

<div class='chapter'>4. The Compiler</div><p class='cindent' id='compiler'><!-- compiler -->
<div class='section'>4.1 The Basic Operations of the Compiler</div>
	The purpose of the Lisp compiler is to convert Lisp functions
into programs in the Lisp Machine's instruction set, so that they
will run more quickly and take up less storage.  Compiled functions
are represented in Lisp by FEFs (Function
Entry Frames), which contain machine code as well as various other information.
The format of FEFs and the instruction set are explained in (section-fef-format).

	There are three ways to invoke the compiler from the Lisp
Machine.  First, you may have an interpreted function in the Lisp
environment which you would like to compile.  The function <font class="lisp">compile</font>
is used to do this.  Second, you may have code in an editor buffer
which you would like to compile.  The EINE editor has commands
to read code into Lisp and compile it.
Third, you may have a program (a group of function definitions and other forms) written in a
file on the file system.  The compiler can translate this file into a
QFASL file.  Loading in the QFASL file is like reading in the source
file, except that the functions in the source file will be compiled.
The <font class="lisp">qc-file</font> function is used for translating source files into QFASL files.

<!-- Explain why the compiler expands macros. -->
<!-- Explain specialness versus localness, etc. -->

<div class='section'>4.2 How to Invoke the Compiler</div>
<div class='defun'><font class='exdent'><font class='funcname'>compile <font class='italic' color='purple'>symbol</font></font></font><br>
<font class="italic">symbol</font> should be defined as an interpreted function (its definition
should be a lambda-expression).  The compiler converts the lambda-expression
into a FEF, saves the lambda-expression as the <font class="lisp">:previous-expr-definition</font>
and <font class="lisp">:previous-definition</font> properties of <font class="italic">symbol</font>, and changes <font class="italic">symbol</font>'s
definition to be the FEF.  (See <font class="lisp">fset-carefully</font>, (fset-carefully-fun).
(Actually, if <font class="italic">symbol</font> is not defined as a lambda-expression,
<font class="lisp">compile</font> will try to find a lambda-expression in the <font class="lisp">:previous-expr-definition</font>
property of <font class="italic">symbol</font> and use that instead.)
</div>

<div class='defun'><font class='exdent'><font class='funcname'>uncompile <font class='italic' color='purple'>symbol</font></font></font><br>
If <font class="italic">symbol</font> is not defined as an interpreted function and it
has a <font class="lisp">:previous-expr-definition</font> property, then <font class="lisp">uncompile</font>
will restore the function cell from the value of the property.
This "undoes" the effect of <font class="lisp">compile</font>.
</div>

<div class='defun'><font class='exdent'><font class='funcname'>qc-file <font class='italic' color='purple'>filename &optional output-file load-flag in-core-flag package</font></font></font><br>
The file <font class="italic">filename</font> is given to the compiler, and the output of the
compiler is written to a file whose name is <font class="italic">filename</font> except with an
FN2 of "QFASL".  The input format for files to the compiler is
described on <a href='compil.html#compiler-input-section'>this link</a>.
Macro definitions and <font class="lisp">special</font> declarations created during
the compilation will be undone when the compilation is
finished.

The optional arguments allow certain modifications to this procedure.
<font class="italic">output-file</font> lets you change where the output is written.
<font class="italic">package</font> lets you specify in what package the source file is to
be read.  Normally the system knows, or asks interactively,
and you need not supply this argument.
<font class="italic">load-flag</font> and <font class="italic">in-core-flag</font> are incomprehensible; you don't
want to use them.
</div>

<div class='defun'><font class='exdent'><font class='funcname'>qc-file-load <font class='italic' color='purple'>filename</font></font></font><br>
<font class="lisp">qc-file-load</font> compiles a file and then loads it in.
</div>

See also the <font class="lisp">disassemble</font> function ((disassemble-fun)), which lists the instructions
of a compiled function in symbolic form.


	The compiler can also be run in Maclisp on ITS.  On the MIT-AI
machine, type :LISPM1;QCMP.  It will type out "READY" and leave you
at a Maclisp top level.  Then type <font class="lisp">(qc-file <font class="italic">filename</font>)</font>,
expressing <font class="italic">filename</font> in Maclisp form.
<pre class="lisp">
<font class='exdent'>Example:</font><!-- exdent -->
(qc-file '((lispm) foo &gt;))
</pre>

<div class='section'>4.3 Input to the Compiler</div><p class='cindent' id='compiler-input-section'><!-- input to the compiler -->
	The purpose of <font class="lisp">qc-file</font> is to take a file and produce
a translated version which does the same thing as the original except
that the functions are compiled.  <font class="lisp">qc-file</font> reads through the input
file, processing the forms in it one by one.  For each form, suitable
binary output is sent to the QFASL file so that when the QFASL file is
loaded the effect of that source form will be reproduced.  The differences
between source files and QFASL files are that QFASL files are in a compressed
binary form which reads much faster (but cannot be edited), and that
function definitions in QFASL files have been translated from S-expressions
to FEFs.

	So, if the source contains a <font class="lisp">(defun ...)</font> form at top
level, then when the QFASL file is loaded, the function will be defined
as a compiled function.  If the source file contains a form which is
not of a type known specially to the compiler, then that form will be
output "directly" into the QFASL file, so that when the QFASL file is
loaded that form will be evaluated.  Thus, if the source file contains
<font class="lisp">(setq x 3)</font>, then the compiler will put in the QFASL file
instructions to set <font class="lisp">x</font> to <font class="lisp">3</font> at load time.

	However, sometimes we want to put things in the file
that are not merely meant to be translated into QFASL form.
One such occasion is top level macro definitions; the macros
must actually get defined within the compiler in order that the
compiler be able to expand them at compile time.  So when a macro
form is seen, it should (sometimes) be evaluated at compile time,
and should (sometimes) be put into the QFASL file.

	Another thing we sometimes want to put in a file is
compiler declarations.  These are forms which should be evaluated
at compile time to tell the compiler something.  They should
not be put into the QFASL file.

	Therefore, a facility exists to allow the user to tell
the compiler just what to do with a form.  One might want a form
to be:
.table 1
.item Put into the QFASL file (translated), or not.
.item Evaluated within the compiler, or not.
.item Evaluated if the file is read directly into Lisp, or not.
.end_table

	Two forms are recognized by the compiler to allow this.  The less
general but Maclisp compatible one is <font class="lisp">declare</font>; the completely
general one is <font class="lisp">eval-when</font>.

	An <font class="lisp">eval-when</font> form looks like
<pre class="lisp">
(eval-when <font class="italic">times-list</font>
	   <font class="italic">form1</font>
	   <font class="italic">form2</font>
           ...)
</pre>
The <font class="italic">times-list</font> may contain any of the symbols <font class="lisp">load</font>, <font class="lisp">compile</font>,
or <font class="lisp">eval</font>.
If <font class="lisp">load</font> is present, the <font class="italic">form</font>s are written into the QFASL file
to be evaluated when the QFASL file is loaded (except that <font class="lisp">defun</font> forms
will put the compiled definition into the QFASL file instead).
If <font class="lisp">compile</font> is present, the <font class="italic">form</font>s are evaluated in the compiler.
If <font class="lisp">eval</font> is present, the <font class="italic">form</font>s are evaluated when read into Lisp;
this is because <font class="lisp">eval-when</font> is defined as a special form in Lisp.  (The
compiler ignores <font class="lisp">eval</font> in the <font class="italic">times-list</font>.)
For example, <font class="lisp">(eval-when (compile eval) (macro foo (x) (cadr x)))</font>
would define <font class="lisp">foo</font> as a macro in the compiler and when the file
is read in interpreted, but not when the QFASL file is fasloaded.

	For the rest of this section, we will use lists such as are
given to <font class="lisp">eval-when</font>, e.g. <font class="lisp">(load eval)</font>, <font class="lisp">(load compile)</font>, etc.
to describe when forms are evaluated.

	A <font class="lisp">declare</font> form looks like <font class="lisp">(declare <font class="italic">form1 form2</font> ...)</font>.
<font class="lisp">declare</font> is defined in Lisp as a special form which does nothing;
so the forms within a <font class="lisp">declare</font> are not evaluated at <font class="lisp">eval</font> time.
The compiler does the following upon finding <font class="italic">form</font> within
a <font class="lisp">declare</font>:  if <font class="italic">form</font> is a call to either <font class="lisp">special</font>
or <font class="lisp">unspecial</font>, <font class="italic">form</font> is treated as <font class="lisp">(load compile)</font>;
otherwise it is treated as <font class="lisp">(compile)</font>.

	If a form is not enclosed in an <font class="lisp">eval-when</font> nor a <font class="lisp">declare</font>,
then the times at which it will be evaluated depend on the form.
The following table summarizes at what times evaluation will take
place for any given form seen at top level by the compiler.
.table 3
.item (eval-when <font class="italic">times-list</font> <font class="italic">form1</font> ...)
<font class="italic">times-list</font>
.item (declare (special ...)) <font class="main">or</font> (declare (unspecial ...))
<font class="lisp">(load compile)</font>
.item (declare <font class="italic">anything-else</font>)
<font class="lisp">(compile)</font>
.item (special ...) <font class="main">or</font> (unspecial ...)
<font class="lisp">(load compile eval)</font>
.item (macro ...) <font class="main">or</font> (defstruct ...)
<font class="lisp">(load compile eval)</font>
.item (comment ...)
Ignored
.item (begf ...) <font class="main">or</font> (endf ...)
Ignored but may one day put something in the QFASL file.
.item (compiler-let ((<font class="italic">var val</font>) ...) <font class="italic">body</font>...)
At <font class="lisp">(compile eval)</font> time, processes the body with the indicated
variable bindings in effect.  Does nothing at <font class="lisp">load</font> time.
.item (local-declare (<font class="italic">decl decl ...</font>) <font class="italic">body</font>...)
Processes the <font class="italic">body</font> in its normal fashion, with the indicated
declarations added to the front of the list which is the value
of <font class="lisp">local-declarations</font>.
.item <font class="italic">anything-else</font>
<font class="lisp">(load eval)</font>
.end_table

	Sometimes a macro wants to return more than one form
for the compiler top level to see (and to be evaluated).  The following
facility is provided for such macros.  If a form
<pre class="lisp">
(progn (quote compile) <font class="italic">form1</font> <font class="italic">form2</font> ...)
</pre>
is seen at the compiler top level, all of the <font class="italic">form</font>s are processed as if they had been at
compiler top level.  (Of course, in the interpreter they
will all be evaluated, and the <font class="lisp">(quote compile)</font> will harmlessly
evaluate to the symbol <font class="lisp">compile</font> and be ignored.)

<div class="defspec"><font class='exdent'><font class='funcname'>eval-when</font><font class="italic"> Special Form</font></font><br>
An <font class="lisp">eval-when</font> form looks like
<pre class="lisp">
(eval-when <font class="italic">times-list</font> <font class="italic">form1</font> <font class="italic">form2</font> ...)
</pre>
If one of the element of <font class="italic">times-list</font> is the symbol <font class="lisp">eval</font>, then
the <font class="italic">form</font>s are evaluated; otherwise <font class="lisp">eval-when</font> does nothing.

But when seen by the compiler, this special form does the special things described above.
</div>

<div class="defspec"><font class='exdent'><font class='funcname'>declare</font><font class="italic"> Special Form</font></font><br>
<font class="lisp">declare</font> does nothing, and returns the symbol <font class="lisp">declare</font>.

But when seen by the compiler, this special form does the special things described above.
</div>

<div class='section'>4.4 Compiler Declarations</div>
	This section describes functions meant to be called during
compilation, and variables meant to be set or bound during compilation,
by using <font class="lisp">declare</font> or <font class="lisp">local-declare</font>.

<div class="defspec"><font class='exdent'><font class='funcname'>local-declare</font><font class="italic"> Special Form</font></font><br>
A <font class="lisp">local-declare</font> form looks like
<pre class="lisp">
(local-declare (<font class="italic">decl1</font> <font class="italic">decl2</font> ...)
   <font class="italic">form1</font>
   <font class="italic">form2</font>
   ...)
</pre>
Each <font class="italic">decl</font> is consed onto the list <font class="lisp">local-declarations</font> while
the <font class="italic">form</font>s are being evaluated (in the interpreter) or compiled
(in the compiler).  There are two uses for this.  First, it can be
used to pass information from outer macros to inner macros.  Secondly,
the compiler will specially interpret certain <font class="italic">decl</font>s as local
declarations, which only apply to the compilations of the <font class="italic">form</font>s.
It understands the following forms:
.table 3
.item (special <font class="italic">var1 var2 ...</font>)
The variables <font class="italic">var1</font>, <font class="italic">var2</font>, etc. will be treated as special
variables during the compilation of the <font class="italic">form</font>s.
.item (unspecial <font class="italic">var1 var2 ...</font>)
The variables <font class="italic">var1</font>, <font class="italic">var2</font>, etc. will be treated as local
variables during the compilation of the <font class="italic">form</font>s.
.item (macro <font class="italic">name</font> lambda (x) <font class="italic">body</font>)
<font class="italic">name</font> will be defined as a macro during the compilation
of the <font class="italic">form</font>s.  Note that the <font class="lisp">cddr</font> of this item
is a function.
.end_table
</div>

<div class="defspec"><font class='exdent'><font class='funcname'>special</font><font class="italic"> Special Form</font></font><br>
<font class="lisp">(special <font class="italic">var1</font> <font class="italic">var2</font> ...)</font> causes the variables to
be declared to be "special" for the compiler. 
</div>

<div class="defspec"><font class='exdent'><font class='funcname'>unspecial</font><font class="italic"> Special Form</font></font><br>
<font class="lisp">(unspecial <font class="italic">var1</font> <font class="italic">var2</font> ...)</font> removes any "special" declarations
of the variables for the compiler.
</div>

The next three declarations are primarily for Maclisp compatibility.

<div class="defspec"><font class='exdent'><font class='funcname'>*expr</font><font class="italic"> Special Form</font></font><br>
<font class="lisp">(*expr <font class="italic">sym1</font> <font class="italic">sym2</font> ...)</font> declares <font class="italic">sym1</font>, <font class="italic">sym2</font>, etc.
to be names of functions.  In addition it prevents these functions from appearing
in the list of functions referenced but not defined printed at the end of the compilation.
</div>

<div class="defspec"><font class='exdent'><font class='funcname'>*lexpr</font><font class="italic"> Special Form</font></font><br>
<font class="lisp">(*lexpr <font class="italic">sym1</font> <font class="italic">sym2</font> ...)</font> declares <font class="italic">sym1</font>, <font class="italic">sym2</font>, etc.
to be names of functions.  In addition it prevents these functions from appearing
in the list of functions referenced but not defined printed at the end of the compilation.
</div>

<div class="defspec"><font class='exdent'><font class='funcname'>*fexpr</font><font class="italic"> Special Form</font></font><br>
<font class="lisp">(*fexpr <font class="italic">sym1</font> <font class="italic">sym2</font> ...)</font> declares <font class="italic">sym1</font>, <font class="italic">sym2</font>, etc.
to be names of special forms.  In addition it prevents these names from appearing
in the list of functions referenced but not defined printed at the end of the compilation.
</div>

	There are some advertised variables whose compile-time values affect
the operation of the compiler.  The user may set these variables by
including in his file forms such as
<pre class="lisp">
(declare (setq open-code-map-switch t))
</pre>

.defvar run-in-maclisp-switch
If this variable is non-<font class="lisp">nil</font>, the compiler will try to warn the
user about any constructs which will not work in Maclisp.  By no means
will all Lisp machine system functions not built in to Maclisp be
cause for warnings;  only those which could not be written by the user
in Maclisp (for example, <font class="lisp">*catch</font>, <font class="lisp">make-array</font>,
<font class="lisp">value-cell-location</font>, etc.).  Also, lambda-list keywords such as
<font class="lisp">&optional</font> and initialized <font class="lisp">prog</font> variables will be
mentioned.  This switch also inhibits the warnings for obsolete Maclisp functions.
The default value of this variable is <font class="lisp">nil</font>.
.end_defvar

.defvar obsolete-function-warning-switch
If this variable is non-<font class="lisp">nil</font>, the compiler will try to warn
the user whenever an "obsolete" Maclisp-compatibility function such as
<font class="lisp">maknam</font> or <font class="lisp">samepnamep</font> is used.  The default value is <font class="lisp">t</font>.
.end_defvar

.defvar allow-variables-in-function-position-switch
If this variable is non-<font class="lisp">nil</font>, the compiler allows the use of
the name of a variable in function position to mean that the
variable's value should be <font class="lisp">funcall</font>'d.  This is for compatibility
with old Maclisp programs.  The default value of this variable is
<font class="lisp">nil</font>.
.end_defvar

.defvar open-code-map-switch
If this variable is non-<font class="lisp">nil</font>, the compiler will attempt
to produce inline code for the mapping functions (<font class="lisp">mapc</font>, <font class="lisp">mapcar</font>, etc.,
but not <font class="lisp">mapatoms</font>) if the function being mapped is an anonymous
lambda-expression.  This allows that function to reference
the local variables of the enclosing function without the need for special
declarations.
The generated code is also more efficient.  The default value is T.
.end_defvar

.defvar all-special-switch
If this variable is non-<font class="lisp">nil</font>, the compiler regards all variables
as special, regardless of how they were declared.  This provides full
compatibility with the interpreter at the cost of efficiency.
The default is <font class="lisp">nil</font>.
.end_defvar

.defvar inhibit-style-warnings-switch
If this variable is non-<font class="lisp">nil</font>, all compiler style-checking is
turned off.  Style checking is used to issue obsolete function
warnings and won't-run-in-Maclisp warnings, and other sorts of
warnings.  The default value is <font class="lisp">nil</font>.  See also the
<font class="lisp">inhibit-style-warnings</font> macro, which acts on one level only of an
expression.
.end_defvar

.defvar retain-variable-names-switch
This controls whether the generated FEFs remember the names of the variables
in the function; such information is useful for debugging
(the <font class="lisp">arglist</font> function uses it, see (arglist-fun)), but it increases
the size of the QFASL file and the FEFs created.  The variable
may be any of
.table 3
.item nil
No names are saved.
.item args
Names of arguments are saved.
.item all
Names of arguments and <font class="lisp">&aux</font> variables are saved.
.end_table
The default value of this symbol is <font class="lisp">args</font>, and it should usually be
left that way.
.end_defvar

<div class='defmac'><font class='exdent'><font class='funcname' id='compiler-let'>compiler-let</font><font class="italic"> Macro</font><br></font><!-- end font_exdent --><br><font class="lisp">(compiler-let ((<font class="italic">variable value</font>)...) <font class="italic">body</font>...)</font>,
syntactically identical to <font class="lisp">let</font>, allows
compiler switches to be bound locally at compile time, during the
processing of the <font class="italic">body</font> forms.
<pre class="lisp">
<font class='exdent'>Example:</font><!-- exdent -->
(compiler-let ((open-code-map-switch nil))
          (map (function (lambda (x) ...)) foo))
</pre>
will prevent the compiler from open-coding the <font class="lisp">map</font>.
When interpreted, <font class="lisp">compiler-let</font> is equivalent to <font class="lisp">let</font>.  This
is so that global switches which affect the behavior of macro
expanders can be bound locally.
</div>

<div class='defmac'><font class='exdent'><font class='funcname' id='inhibit-style-warnings'>inhibit-style-warnings</font><font class="italic"> Macro</font><br></font><!-- end font_exdent --><br><font class="lisp">(inhibit-style-warnings <font class="italic">form</font>)</font>
prevents the compiler from performing style-checking on the top level
of <font class="italic">form</font>.  Style-checking will still be done on the arguments of <font class="italic">form</font>.
Both obsolete function warnings and won't-run-in-Maclisp warnings are
done by means of the style-checking mechanism, so, for example,
<pre class="lisp">
(setq bar (inhibit-style-warnings (value-cell-location foo)))
</pre>
will not warn that <font class="lisp">value-cell-location</font> will not work in Maclisp,
but
<pre class="lisp">
(inhibit-style-warnings (setq bar (value-cell-location foo)))
</pre>
will warn, since <font class="lisp">inhibit-style-warnings</font> applies only to the top
level of the form inside it (in this case, to the <font class="lisp">setq</font>).
</div>

<div class='section'>4.5 Compiler Source-Level Optimizers</div>
The compiler stores optimizers for source code on property lists so as
to make it easy for the user to add them.  An optimizer can be used to
transform code into an equivalent but more efficient form (for
example, <font class="lisp">(eq <font class="italic">obj</font> nil)</font> is transformed into <font class="lisp">(null <font class="italic">obj</font>)</font>,
which can be compiled better).  An optimizer can also be used to
tell the compiler how to compile a special form.  For example,
in the interpreter <font class="lisp">do</font> is a special form, implemented by a function
which takes quoted arguments and calls <font class="lisp">eval</font>.  In the compiler,
<font class="lisp">do</font> is expanded in a macro-like way by an optimizer, into
equivalent Lisp code using <font class="lisp">prog</font>, <font class="lisp">cond</font>, and <font class="lisp">go</font>, which
the compiler understands.

The compiler finds the optimizers to apply to a form by looking for
the <font class="lisp">compiler:optimizers</font> property of the symbol which is the
<font class="lisp">car</font> of the form.  The value of this property should be a list of
optimizers, each of which must be a function of one argument.  The
compiler tries each optimizer in turn, passing the form to be
optimized as the argument.  An optimizer which returns the original
form unchanged (and <font class="lisp">eq</font> to the argument) has "done nothing", and
the next optimizer is tried.  If the optimizer returns anything else,
it has "done something", and the whole process starts over again.
This is somewhat like a Markov algorithm.  Only after all the optimizers
have been tried and have done nothing is an ordinary macro definition
processed.  This is so that the macro definitions, which will be seen
by the interpreter, can be overridden for the compiler by an optimizer.

<div class='section'>4.6 Files that Maclisp Must Compile</div>
Certain programs are intended to be run both in Maclisp and in Lisp
Machine Lisp.  These files need some special conventions.  For example,
such Lisp Machine constructs as <font class="lisp">&aux</font> and <font class="lisp">&optional</font> must not be
used.  In addition, <font class="lisp">eval-when</font> must not be used, since only the Lisp
Machine compiler knows about it.  All <font class="lisp">special</font> declarations must be
enclosed in <font class="lisp">declare</font>s, so that the Maclisp compiler will see them.
It is suggested that you turn on <font class="lisp">run-in-maclisp-switch</font>
in such files, which will warn you about a lot of bugs.

The macro-character combination "#Q" causes the object that
follows it to be visible only when compiling for the Lisp Machine.
The combination "#M" causes the  following object to be visible
only when compiling for Maclisp.  These work only on subexpressions
of the objects in the file, however.  To conditionalize top-level objects,
put the macros <font class="lisp">if-for-lispm</font> and
<font class="lisp">if-for-maclisp</font> around them.  (You can only put these around
a single object.)  The <font class="lisp">if-for-lispm</font> macro turns off <font class="lisp">run-in-maclisp-switch</font>
within its object, preventing spurious warnings from the compiler.
The <font class="lisp">#Q</font> macro-character does not do this, since it can be used
to conditionalize any S-expression, not just a top-level form.

	There are actually three possible cases of compiling: you may
be compiling on the Lisp Machine for the Lisp Machine; you may
be compiling in Maclisp for the Lisp Machine (with :LISPM1;QCMP);
or you may be compiling in Maclisp for Maclisp (with COMPLR).
(You can't compile for Maclisp on the Lisp Machine because there isn't a Lisp
Machine Lisp version of COMPLR.)  To allow a file to detect any
of these conditions it needs to, the following macros are provided:

<div class='defmac'><font class='exdent'><font class='funcname' id='if-for-lispm'>if-for-lispm</font><font class="italic"> Macro</font><br></font><!-- end font_exdent --><br>If <font class="lisp">(if-for-lispm <font class="italic">form</font>)</font> is seen at the top level of
the compiler, <font class="italic">form</font> is passed to the compiler top level if
the output of the compiler is a QFASL file intended for the Lisp Machine.
If the Lisp Machine interpreter sees this it will evaluate <font class="italic">form</font>
(the macro expands into <font class="italic">form</font>).
</div>

<div class='defmac'><font class='exdent'><font class='funcname' id='if-for-maclisp'>if-for-maclisp</font><font class="italic"> Macro</font><br></font><!-- end font_exdent --><br>If <font class="lisp">(if-for-maclisp <font class="italic">form</font>)</font> is seen at the top level of
the compiler, <font class="italic">form</font> is passed to the compiler top level if
the output of the compiler is a FASL file intended for Maclisp
(e.g. if the compiler is COMPLR).
If the Lisp Machine interpreter sees this it will ignore it
(the macro expands into <font class="lisp">nil</font>).
</div>

<div class='defmac'><font class='exdent'><font class='funcname' id='if-for-maclisp-else-lispm'>if-for-maclisp-else-lispm</font><font class="italic"> Macro</font><br></font><!-- end font_exdent --><br>If <font class="lisp">(if-for-maclisp-else-lispm <font class="italic">form1</font> <font class="italic">form2</font>)</font> is seen at the top level of
the compiler, <font class="italic">form1</font> is passed to the compiler top level if
the output of the compiler is a FASL file intended for Maclisp;
otherwise <font class="italic">form2</font> is passed to the compiler top level.
</div>

<div class='defmac'><font class='exdent'><font class='funcname' id='if-in-lispm'>if-in-lispm</font><font class="italic"> Macro</font><br></font><!-- end font_exdent --><br>On the Lisp Machine, <font class="lisp">(if-in-lispm <font class="italic">form</font>)</font> causes <font class="italic">form</font>
to be evaluated; in Maclisp, <font class="italic">form</font> is ignored.
</div>

<div class='defmac'><font class='exdent'><font class='funcname' id='if-in-maclisp'>if-in-maclisp</font><font class="italic"> Macro</font><br></font><!-- end font_exdent --><br>In Maclisp, <font class="lisp">(if-in-maclisp <font class="italic">form</font>)</font> causes <font class="italic">form</font>
to be evaluated; on the Lisp Machine, <font class="italic">form</font> is ignored.
</div>

	When you have two definitions of one function, one conditionalized
for one machine and one for the other, indent the first "<font class="lisp">(defun</font>"
by one space, and the editor will put both function definitions together
in the same file-section.

	In order to make sure that those macros and macro-characters are
defined when reading the file into the Maclisp compiler, you must
make the file start with a prelude, which will have no effect
when you compile on the real machine.  The prelude can
be found in "AI: LMDOC; .COMPL PRELUD"; this will also define
most of the standard Lisp Machine macros and reader macros in Maclisp, including
<font class="lisp">defmacro</font> and the backquote facility.

	Another useful facility is the form <font class="lisp">(status feature lispm)</font>,
which evaluates to <font class="lisp">t</font> when evaluated on the Lisp machine and to <font class="lisp">nil</font>
when evaluated in Maclisp.
.eof
</body>
</html>

